home *** CD-ROM | disk | FTP | other *** search
/ Chip: Internet / Chip Internet.iso / viewer / jpeg-faq.txt next >
Text File  |  1995-07-12  |  80KB  |  1,488 lines
  1.  
  2. Archive-name: jpeg-faq/part1
  3. Posting-Frequency: every 14 days
  4. Last-modified: 28 May 1995
  5.  
  6. This article answers Frequently Asked Questions about JPEG image compression.
  7. This is part 1, covering general questions and answers about JPEG.  Part 2
  8. gives system-specific hints and program recommendations.  As always,
  9. suggestions for improvement of this FAQ are welcome.
  10.  
  11. New since version of 13 May 1995:
  12.   * Sec. 14: added info about bogus "JFIF 2.01" files being written by Hijaak.
  13.  
  14.  
  15. This article includes the following sections:
  16.  
  17. Basic questions:
  18.  
  19. [1] What is JPEG?
  20. [2] Why use JPEG?
  21. [3] When should I use JPEG, and when should I stick with GIF?
  22. [4] How well does JPEG compress images?
  23. [5] What are good "quality" settings for JPEG?
  24. [6] Where can I get JPEG software?
  25. [7] How do I view JPEG images posted on Usenet?
  26.  
  27. More advanced questions:
  28.  
  29. [8] What is color quantization?
  30. [9] What are some rules of thumb for converting GIF images to JPEG?
  31. [10] Does loss accumulate with repeated compression/decompression?
  32. [11] What is progressive JPEG?
  33. [12] Isn't there a lossless JPEG?
  34. [13] Why all the argument about file formats?
  35. [14] How do I recognize which file format I have, and what do I do about it?
  36. [15] How does JPEG work?
  37. [16] What about arithmetic coding?
  38. [17] Could an FPU speed up JPEG?  How about a DSP chip?
  39. [18] Isn't there an M-JPEG standard for motion pictures?
  40. [19] What if I need more than 8-bit precision?
  41.  
  42. Miscellaneous:
  43.  
  44. [20] Where are FAQ lists archived?
  45.  
  46.  
  47. This article and its companion are posted every 2 weeks.  If you can't find
  48. part 2, you can get it from the news.answers archive at rtfm.mit.edu
  49. (see "[20] Where are FAQ lists archived?").  Part 2 changes very frequently;
  50. get a new copy if the one you are reading is more than a couple months old.
  51.  
  52. ------------------------------
  53.  
  54. Subject: [1] What is JPEG?
  55.  
  56. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  57. JPEG stands for Joint Photographic Experts Group, the original name of the
  58. committee that wrote the standard.
  59.  
  60. JPEG is designed for compressing either full-color or gray-scale images
  61. of natural, real-world scenes.  It works well on photographs, naturalistic
  62. artwork, and similar material; not so well on lettering, simple cartoons,
  63. or line drawings.  JPEG handles only still images, but there is a related
  64. standard called MPEG for motion pictures.
  65.  
  66. JPEG is "lossy," meaning that the decompressed image isn't quite the same as
  67. the one you started with.  (There are lossless image compression algorithms,
  68. but JPEG achieves much greater compression than is possible with lossless
  69. methods.)  JPEG is designed to exploit known limitations of the human eye,
  70. notably the fact that small color changes are perceived less accurately than
  71. small changes in brightness.  Thus, JPEG is intended for compressing images
  72. that will be looked at by humans.  If you plan to machine-analyze your
  73. images, the small errors introduced by JPEG may be a problem for you, even
  74. if they are invisible to the eye.
  75.  
  76. A useful property of JPEG is that the degree of lossiness can be varied by
  77. adjusting compression parameters.  This means that the image maker can trade
  78. off file size against output image quality.  You can make *extremely* small
  79. files if you don't mind poor quality; this is useful for applications such
  80. as indexing image archives.  Conversely, if you aren't happy with the output
  81. quality at the default compression setting, you can jack up the quality
  82. until you are satisfied, and accept lesser compression.
  83.  
  84. Another important aspect of JPEG is that decoders can trade off decoding
  85. speed against image quality, by using fast but inaccurate approximations to
  86. the required calculations.  Some viewers obtain remarkable speedups in this
  87. way.
  88.  
  89. ------------------------------
  90.  
  91. Subject: [2] Why use JPEG?
  92.  
  93. There are two good reasons: to make your image files smaller, and to store
  94. 24-bit-per-pixel color data instead of 8-bit-per-pixel data.
  95.  
  96. Making image files smaller is a win for transmitting files across networks
  97. and for archiving libraries of images.  Being able to compress a 2 Mbyte
  98. full-color file down to, say, 100 Kbytes makes a big difference in disk
  99. space and transmission time!  And JPEG can easily provide 20:1 compression
  100. of full-color data.  If you are comparing GIF and JPEG, the size ratio is
  101. usually more like 4:1 (see "[4] How well does JPEG compress images?").
  102.  
  103. If your viewing software doesn't support JPEG directly, you'll have to
  104. convert JPEG to some other format to view the image.  Even with a
  105. JPEG-capable viewer, it takes longer to decode and view a JPEG image than
  106. to view an image of a simpler format such as GIF.  Thus, using JPEG is
  107. essentially a time/space tradeoff: you give up some time in order to store
  108. or transmit an image more cheaply.  But it's worth noting that when network
  109. or telephone transmission is involved, the time savings from transferring a
  110. shorter file can be greater than the time needed to decompress the file.
  111.  
  112. The second fundamental advantage of JPEG is that it stores full color
  113. information: 24 bits/pixel (16 million colors).  GIF, the other image format
  114. widely used on Usenet, can only store 8 bits/pixel (256 or fewer colors).
  115. GIF is reasonably well matched to inexpensive computer displays --- most
  116. run-of-the-mill PCs can't display more than 256 distinct colors at once.
  117. But full-color hardware is getting cheaper all the time, and JPEG images
  118. look *much* better than GIFs on such hardware.  Within a couple of years,
  119. GIF will probably seem as obsolete as black-and-white MacPaint format does
  120. today.  Furthermore, JPEG is far more useful than GIF for exchanging images
  121. among people with widely varying display hardware, because it avoids
  122. prejudging how many colors to use (see "[8] What is color quantization?").
  123. Hence JPEG is considerably more appropriate than GIF for use as a Usenet
  124. posting standard.
  125.  
  126. A lot of people are scared off by the term "lossy compression".  But when
  127. it comes to representing real-world scenes, *no* digital image format can
  128. retain all the information that impinges on your eyeball.  By comparison
  129. with the real-world scene, JPEG loses far less information than GIF.
  130. The real disadvantage of lossy compression is that if you repeatedly
  131. compress and decompress an image, you lose a little quality each time
  132. (see "[10] Does loss accumulate with repeated compression/decompression?").
  133. This is a serious objection for some applications but matters not at all
  134. for many others.
  135.  
  136. ------------------------------
  137.  
  138. Subject: [3] When should I use JPEG, and when should I stick with GIF?
  139.  
  140. JPEG is *not* going to displace GIF entirely; for some types of images,
  141. GIF is superior in image quality, file size, or both.  One of the first
  142. things to learn about JPEG is which kinds of images to apply it to.
  143.  
  144. Generally speaking, JPEG is superior to GIF for storing full-color or
  145. gray-scale images of "realistic" scenes; that means scanned photographs and
  146. similar material.  Any continuous variation in color, such as occurs in
  147. highlighted or shaded areas, will be represented more faithfully and in less
  148. space by JPEG than by GIF.
  149.  
  150. GIF does significantly better on images with only a few distinct colors,
  151. such as line drawings and simple cartoons.  Not only is GIF lossless for
  152. such images, but it often compresses them more than JPEG can.  For example,
  153. large areas of pixels that are all *exactly* the same color are compressed
  154. very efficiently indeed by GIF.  JPEG can't squeeze such data as much as GIF
  155. does without introducing visible defects.  (One implication of this is that
  156. large single-color borders are quite cheap in GIF files, while they are best
  157. avoided in JPEG files.)
  158.  
  159. Computer-drawn images, such as ray-traced scenes, usually fall between
  160. photographs and cartoons in terms of complexity.  The more complex and
  161. subtly rendered the image, the more likely that JPEG will do well on it.
  162. The same goes for semi-realistic artwork (fantasy drawings and such).
  163. But icons that use only a few colors are handled better by GIF.
  164.  
  165. JPEG has a hard time with very sharp edges: a row of pure-black pixels
  166. adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
  167. come out blurred unless you use a very high quality setting.  Edges this
  168. sharp are rare in scanned photographs, but are fairly common in GIF files:
  169. consider borders, overlaid text, etc.  The blurriness is particularly
  170. objectionable with text that's only a few pixels high.  If you have a GIF
  171. with a lot of small-size overlaid text, don't JPEG it.  (If you want to
  172. attach descriptive text to a JPEG image, put it in as a comment rather than
  173. trying to overlay it on the image.  Most recent JPEG software can deal with
  174. textual comments in a JPEG file, although older viewers may just ignore the
  175. comments.)
  176.  
  177. Plain black-and-white (two level) images should never be converted to JPEG;
  178. they violate all of the conditions given above.  You need at least about
  179. 16 gray levels before JPEG is useful for gray-scale images.  It should also
  180. be noted that GIF is lossless for gray-scale images of up to 256 levels,
  181. while JPEG is not.
  182.  
  183. If you have a large library of GIF images, you may want to save space by
  184. converting the GIFs to JPEG.  This is trickier than it may seem --- even
  185. when the GIFs contain photographic images, they are actually very poor
  186. source material for JPEG, because the images have been color-reduced.
  187. Non-photographic images should generally be left in GIF form.  Good-quality
  188. photographic GIFs can often be converted with no visible quality loss, but
  189. only if you know what you are doing and you take the time to work on each
  190. image individually.  Otherwise you're likely to lose a lot of image quality
  191. or waste a lot of disk space ... quite possibly both.  Read sections 8 and 9
  192. if you want to convert GIFs to JPEG.
  193.  
  194. ------------------------------
  195.  
  196. Subject: [4] How well does JPEG compress images?
  197.  
  198. Very well indeed, when working with its intended type of image (photographs
  199. and suchlike).  For full-color images, the uncompressed data is normally 24
  200. bits/pixel.  The best known lossless compression methods can compress such
  201. data about 2:1 on average.  JPEG can typically achieve 10:1 to 20:1
  202. compression without visible loss, bringing the effective storage requirement
  203. down to 1 to 2 bits/pixel.  30:1 to 50:1 compression is possible with small
  204. to moderate defects, while for very-low-quality purposes such as previews or
  205. archive indexes, 100:1 compression is quite feasible.  An image compressed
  206. 100:1 with JPEG takes up the same space as a full-color one-tenth-scale
  207. thumbnail image, yet it retains much more detail than such a thumbnail.
  208.  
  209. For comparison, a GIF version of the same image would start out by
  210. sacrificing most of the color information to reduce the image to 256 colors
  211. (8 bits/pixel).  This provides 3:1 compression.  GIF has additional "LZW"
  212. compression built in, but LZW doesn't work very well on typical photographic
  213. data; at most you may get 5:1 compression overall, and it's not at all
  214. uncommon for LZW to be a net loss (i.e., less than 3:1 overall compression).
  215. LZW *does* work well on simpler images such as line drawings, which is why
  216. GIF handles that sort of image so well.  When a JPEG file is made from
  217. full-color photographic data, using a quality setting just high enough to
  218. prevent visible loss, the JPEG will typically be a factor of four or five
  219. smaller than a GIF file made from the same data.
  220.  
  221. Gray-scale images do not compress by such large factors.  Because the human
  222. eye is much more sensitive to brightness variations than to hue variations,
  223. JPEG can compress hue data more heavily than brightness (gray-scale) data.
  224. A gray-scale JPEG file is generally only about 10%-25% smaller than a
  225. full-color JPEG file of similar visual quality.  But the uncompressed
  226. gray-scale data is only 8 bits/pixel, or one-third the size of the color
  227. data, so the calculated compression ratio is much lower.  The threshold of
  228. visible loss is often around 5:1 compression for gray-scale images.
  229.  
  230. The exact threshold at which errors become visible depends on your viewing
  231. conditions.  The smaller an individual pixel, the harder it is to see an
  232. error; so errors are more visible on a computer screen (at maybe 70
  233. dots/inch) than on a high-quality color printout (300 or more dots/inch).
  234. Thus a higher-resolution image can tolerate more compression ... which is
  235. fortunate considering it's much bigger to start with.  The numbers quoted
  236. above are typical for screen viewing.  Also note that the threshold of
  237. visible error varies considerably across images.
  238.  
  239. ------------------------------
  240.  
  241. Subject: [5] What are good "quality" settings for JPEG?
  242.  
  243. Most JPEG compressors let you pick a file size vs. image quality tradeoff by
  244. selecting a quality setting.  There seems to be widespread confusion about
  245. the meaning of these settings.  "Quality 95" does NOT mean "keep 95% of the
  246. information", as some have claimed.  The quality scale is purely arbitrary;
  247. it's not a percentage of anything.
  248.  
  249. In fact, quality scales aren't even standardized across JPEG programs.
  250. The quality settings discussed in this article apply to the free IJG JPEG
  251. software (described in part 2), and to many programs based on it.  Other
  252. JPEG implementations, notably Apple's and HSI's, use completely different
  253. quality scales; for instance, Apple's scale runs from 0-4, not 0-100.  Some
  254. programs don't even provide a numeric scale, just "high"/"medium"/"low"
  255. style choices.  (Fortunately, this doesn't prevent different implementations
  256. from exchanging compressed files.)
  257.  
  258. In most cases the user's goal is to pick the lowest quality setting, or
  259. smallest file size, that decompresses into an image indistinguishable from
  260. the original.  This setting will vary from one image to another and from one
  261. observer to another, but here are some rules of thumb.
  262.  
  263. For good-quality, full-color source images, the default IJG quality setting
  264. (Q 75) is very often the best choice.  This setting is about the lowest you
  265. can go without expecting to see defects in a typical image.  Try Q 75 first;
  266. if you see defects, then go up.
  267.  
  268. If the image was less than perfect quality to begin with, you might be able
  269. to drop down to Q 50 without objectionable degradation.  On the other hand,
  270. you might need to go to a *higher* quality setting to avoid further loss.
  271. This is often necessary if the image contains dithering or moire patterns
  272. (see "[9] What are some rules of thumb for converting GIF images to JPEG?").
  273.  
  274. Except for experimental purposes, never go above about Q 95; using Q 100
  275. will produce a file two or three times as large as Q 95, but of hardly any
  276. better quality.  If you see a file made with Q 100, it's a pretty sure sign
  277. that the maker didn't know what he/she was doing.
  278.  
  279. If you want a very small file (say for preview or indexing purposes) and are
  280. prepared to tolerate large defects, a Q setting in the range of 5 to 10 is
  281. about right.  Q 2 or so may be amusing as "op art".  (It's worth mentioning
  282. that the current IJG software is not optimized for such low quality factors.
  283. Future versions may achieve better image quality for the same file size at
  284. low quality settings.)
  285.  
  286. ------------------------------
  287.  
  288. Subject: [6] Where can I get JPEG software?
  289.  
  290. See part 2 of this FAQ for recommendations about programs for particular
  291. systems.  Part 2 also tells where to find free C source code for
  292. implementing JPEG, in case you want to write your own programs using JPEG.
  293.  
  294. The comp.graphics FAQs and the alt.binaries.pictures FAQ are more general
  295. sources of information about graphics programs available on the Internet
  296. (see "[20] Where are FAQ lists archived?").
  297.  
  298. ------------------------------
  299.  
  300. Subject: [7] How do I view JPEG images posted on Usenet?
  301.  
  302. Image files posted on the alt.binaries.pictures.* newsgroups are usually
  303. "uuencoded".  Uuencoding converts binary image data into text that can
  304. safely be posted.  Most posters also divide large posts into multiple parts,
  305. since some news software can't cope with big articles.  Before your viewer
  306. will recognize the image, you must combine the parts into one file and run
  307. the text through a uudecode program.  (This is all true for GIF as well as
  308. JPEG, by the way.)  There are programs available to automate this process.
  309.  
  310. For more info see the alt.binaries.pictures FAQ, which is available from
  311. rtfm.mit.edu:/pub/usenet/news.answers/pictures-faq/part[1-3], or on WWW at
  312. http://www.cis.ohio-state.edu/hypertext/faq/usenet/pictures-faq/top.html
  313. (see also "[20] Where are FAQ lists archived?").
  314.  
  315. ------------------------------
  316.  
  317. Subject: [8] What is color quantization?
  318.  
  319. Most people don't have full-color (24 bit per pixel) display hardware.
  320. Typical display hardware stores 8 or fewer bits per pixel, so it can display
  321. 256 or fewer distinct colors at a time.  To display a full-color image, the
  322. computer must choose an appropriate set of representative colors and map the
  323. image into these colors.  This process is called "color quantization".
  324. (This is something of a misnomer; "color selection" or "color reduction"
  325. would be a better term.  But we're stuck with the standard usage.)
  326.  
  327. Clearly, color quantization is a lossy process.  It turns out that for most
  328. images, the details of the color quantization algorithm have *much* more
  329. impact on the final image quality than do any errors introduced by JPEG
  330. itself (except at the very lowest JPEG quality settings).  Making a good
  331. color quantization method is a black art, and no single algorithm is best
  332. for all images.
  333.  
  334. Since JPEG is a full-color format, displaying a color JPEG image on
  335. 8-bit-or-less hardware requires color quantization.  The speed and image
  336. quality of a JPEG viewer running on such hardware are largely determined by
  337. its quantization algorithm.  Depending on whether a quick-and-dirty or
  338. good-but-slow method is used, you'll see great variation in image quality
  339. among viewers on 8-bit displays, much more than occurs on 24-bit displays.
  340.  
  341. On the other hand, a GIF image has already been quantized to 256 or fewer
  342. colors.  (A GIF always has a specific number of colors in its palette, and
  343. the format doesn't allow more than 256 palette entries.)  GIF has the
  344. advantage that the image maker precomputes the color quantization, so
  345. viewers don't have to; this is one of the things that make GIF viewers
  346. faster than JPEG viewers.  But this is also the *disadvantage* of GIF:
  347. you're stuck with the image maker's quantization.  If the maker quantized to
  348. a different number of colors than what you can display, you'll either waste
  349. display capability or else have to requantize to reduce the number of colors
  350. (which usually results in much poorer image quality than quantizing once
  351. from a full-color image).  Furthermore, if the maker didn't use a
  352. high-quality color quantization algorithm, you're out of luck --- the image
  353. is ruined.
  354.  
  355. For this reason, JPEG promises significantly better image quality than GIF
  356. for all users whose machines don't match the image maker's display hardware.
  357. JPEG's full color image can be quantized to precisely match the viewer's
  358. display hardware.  Furthermore, you will be able to take advantage of future
  359. improvements in quantization algorithms, or purchase better display
  360. hardware, to get a better view of JPEG images you already have.  With a GIF,
  361. you're stuck forevermore with what was sent.
  362.  
  363. A growing number of people have better-than-8-bit display hardware already:
  364. 15-bit "hi-color" PC displays, true 24-bit displays on workstations and
  365. Macintoshes, etc.  For these people, GIF is already obsolete, as it cannot
  366. represent an image to the full capabilities of their display.  JPEG images
  367. can drive these displays much more effectively.
  368.  
  369. In short, JPEG is an all-around better choice than GIF for representing
  370. photographic images in a machine-independent fashion.
  371.  
  372.  
  373. It's sometimes thought that a JPEG converted from a GIF shouldn't require
  374. color quantization.  This is false: even when you feed a 256-or-less-color
  375. GIF into JPEG, what comes out of the decompressor is not 256 colors, but
  376. thousands of colors.  This happens because JPEG's lossiness affects each
  377. pixel a little differently, so two pixels that started with identical colors
  378. will usually come out with slightly different colors.  Considering the whole
  379. image, each original color gets "smeared" into a group of nearby colors.
  380. Therefore quantization is always required to display a color JPEG on a
  381. colormapped display, regardless of the image source.
  382.  
  383. The same effect makes it nearly meaningless to talk about the number of
  384. colors used by a JPEG image.  Even if you tried to count the number of
  385. distinct pixel values, different JPEG decoders would give you different
  386. results because of roundoff error differences.  I occasionally see posted
  387. images described as "256-color JPEG".  This tells me that the poster
  388. (a) hasn't read this FAQ and (b) probably converted the JPEG from a GIF.
  389. JPEGs can be classified as color or gray-scale, but number of colors just
  390. isn't a useful concept for JPEG, any more than it is for a real photograph.
  391.  
  392. ------------------------------
  393.  
  394. Subject: [9] What are some rules of thumb for converting GIF images to JPEG?
  395.  
  396. Converting GIF files to JPEG is a tricky business --- you are piling one set
  397. of limitations atop a quite different set, and the results can be awful.
  398. Certainly a JPEG made from a GIF will never be as good as a JPEG made from
  399. true 24-bit color data.  But if what you've got is GIFs, and you need to
  400. save space, here are some hints for getting the best results.
  401.  
  402. With care and a clean source image, it's often possible to make a JPEG of
  403. quality equivalent to the GIF.  This does not mean that the JPEG looks
  404. pixel-for-pixel identical to the GIF --- it won't.  Especially not on an
  405. 8-bit display, because the color quantization process used to display the
  406. JPEG probably won't quite match the quantization process used to make the
  407. GIF from the original data (see "[8] What is color quantization?").  But
  408. remember that the GIF itself is not all that faithful to the full-color
  409. original, if you look at individual pixels.  Looking at the overall image,
  410. a converted JPEG can look as good as its GIF source.  Some people claim that
  411. on 24-bit displays, a carefully converted JPEG can actually look better than
  412. the GIF source, because dither patterns have been eliminated.  (More about
  413. dithering in a moment.)
  414.  
  415. On the other hand, JPEG conversion absolutely *will* degrade an unsuitable
  416. image or one that is converted carelessly.  If you are not willing to take
  417. the amount of trouble suggested below, you're much better off leaving your
  418. GIF images alone.  Simply cranking the JPEG quality setting up to a very
  419. high value wastes space (which defeats the whole point of the exercise, no?)
  420. and some images will be degraded anyway.
  421.  
  422. The first rule is never to convert an image that's not appropriate for JPEG
  423. (see "[3] When should I use JPEG, and when should I stick with GIF?").
  424. Large, high-visual-quality photographic images are usually the best source
  425. material.  And they take up lots of space in GIF form, so they offer
  426. significant potential space savings.  (A good rule of thumb is not to bother
  427. converting any GIF that's much under 100 Kbytes; the potential savings isn't
  428. worth the hassle.)
  429.  
  430. The second rule is to look at each JPEG, to make sure you are happy with it,
  431. before throwing away the corresponding GIF.  This will give you a chance to
  432. re-do the conversion with a higher quality setting if necessary.  Also
  433. compare the file sizes --- if the image isn't suitable JPEG material, a JPEG
  434. file of reasonable quality may come out *larger* than the GIF.
  435.  
  436. The third rule is to get rid of the border.  Many people have developed
  437. an odd habit of putting a large single-color border around a GIF image.
  438. While useless, this is nearly free in terms of storage cost in GIF files.
  439. It is *not* free in JPEG files, either in storage space or in decoding time.
  440. Worse, the sharp border boundary can create visible artifacts ("ghost" edges).
  441. Furthermore, when viewing a bordered JPEG on an 8-bit display, the quantizer
  442. will think the border color is important because there's so much of it, and
  443. hence will waste color palette entries on the border, thus actually reducing
  444. the displayed quality of the main part of the image!  So do yourself a favor
  445. and crop off any border before JPEGing.
  446.  
  447. The fourth rule is to know where the image came from.  Repeated GIF<=>JPEG
  448. conversions are guaranteed to turn an image into mush, because you pay a
  449. quality-loss price on each round trip.  Don't reconvert images that have
  450. been converted before.
  451.  
  452. Gray-scale images usually convert without much problem.  When using cjpeg,
  453. be sure to use the -gray switch.  (Otherwise, cjpeg treats a GIF as color
  454. data; this works, but it wastes space and time if the image is really only
  455. gray-scale.)  Quality settings around the default (75) are usually fine.
  456.  
  457. Color images are much trickier.  Color GIFs of photographic images are
  458. usually "dithered" to fool your eye into seeing more than the 256 colors
  459. that GIF can actually store.  If you enlarge the image, you will find that
  460. adjacent pixels are often of significantly different colors; at normal size
  461. the eye averages these pixels together to produce the illusion of an
  462. intermediate color value.  The trouble with dithering is that, to JPEG, it
  463. looks like high-spatial-frequency color noise; and JPEG can't compress noise
  464. very well.  The resulting JPEG file is both larger and of lower image
  465. quality than what you would have gotten from JPEGing the original full color
  466. image (if you had it).  To get around this, you need to "smooth" the GIF
  467. image before compression.  Smoothing averages together nearby pixels, thus
  468. approximating the color that you thought you saw anyway, and in the process
  469. getting rid of the rapid color changes that give JPEG trouble.  Proper use
  470. of smoothing will both reduce the size of the compressed file and give you a
  471. better-looking output image than you'd get without smoothing.
  472.  
  473. With the IJG JPEG software (cjpeg or derived programs), a simple smoothing
  474. capability is built in.  Try "-smooth 10" or so when converting GIFs.
  475. Values of 10 to 25 seem to work well for high-quality GIFs.  GIFs with
  476. heavy-handed dithering may require larger smoothing factors.  (If you can
  477. see regular fine-scale patterns on the GIF image even without enlargement,
  478. then strong smoothing is definitely called for.)  Too large a smoothing
  479. factor will blur the output image, which you don't want.  If you are an
  480. image processing wizard, you can also do smoothing with a separate filtering
  481. program, but appropriate use of such tools is beyond the scope of this FAQ.
  482.  
  483. Quality settings around 85 (a bit higher than default) usually work well
  484. when converting color GIFs, assuming that you've picked a good smoothing
  485. factor.  You may need still higher quality settings if you can't hide the
  486. dithering pattern with a reasonable smoothing factor.  Really badly dithered
  487. GIFs are best left as GIFs.
  488.  
  489. Don't expect JPEG files converted from GIFs to be as small as those created
  490. directly from full-color originals.  The dithering noise wastes space, but
  491. you won't be able to smooth away all the noise without blurring the image.
  492. Typically, a good-quality converted JPEG will be one-half to one-third the
  493. size of the GIF file, not one-fourth as suggested in section 4.  If the JPEG
  494. comes out much more than half the size of the GIF, this is a good sign that
  495. the image shouldn't be converted at all.
  496.  
  497. The upshot of all this is that "cjpeg -quality 85 -smooth 10" is probably a
  498. good starting point for converting color GIFs.  But if you care about the
  499. image, you'll want to check the results and maybe try a few other settings.
  500. Blindly converting a large GIF library at this or any other setting is a
  501. recipe for disaster.
  502.  
  503. ------------------------------
  504.  
  505. Subject: [10] Does loss accumulate with repeated compression/decompression?
  506.  
  507. It would be nice if, having compressed an image with JPEG, you could
  508. decompress it, manipulate it (crop off a border, say), and recompress it
  509. without any further image degradation beyond what you lost initially.
  510. Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
  511. image loses more information.  Hence it's important to minimize the number
  512. of generations of JPEG compression between initial and final versions of an
  513. image.
  514.  
  515. It turns out that if you decompress and recompress an image at the same
  516. quality setting first used, little or no further degradation occurs.  This
  517. means that you can make local modifications to a JPEG image without material
  518. degradation of other areas of the image.  The areas you change will degrade,
  519. however.  Counterintuitively, this works better the lower the quality
  520. setting.  But you must use *exactly* the same setting, or all bets are off.
  521. Also, the decompressed image must be saved in a full-color format; if you do
  522. JPEG=>GIF=>JPEG, the color quantization step loses lots of information.
  523.  
  524. Unfortunately, cropping doesn't count as a local change!  JPEG processes
  525. the image in small blocks, and cropping usually moves the block boundaries,
  526. so that the image looks completely different to JPEG.  You can take
  527. advantage of the low-degradation behavior if you are careful to crop the
  528. top and left margins only by a multiple of the block size (typically 16
  529. pixels), so that the remaining blocks start in the same places.
  530.  
  531. The bottom line is that JPEG is a useful format for archival storage and
  532. transmission of images, but you don't want to use it as an intermediate
  533. format for sequences of image manipulation steps.  Use a lossless 24-bit
  534. format (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when
  535. you are ready to file it away.  Aside from avoiding degradation, you will
  536. save a lot of compression/decompression time this way :-).
  537.  
  538. ------------------------------
  539.  
  540. Subject: [11] What is progressive JPEG?
  541.  
  542. A simple or "baseline" JPEG file is stored as one top-to-bottom scan of the
  543. image.  Progressive JPEG allows the image to be stored as a series of scans
  544. of increasing quality.  The first scan shows the image at the equivalent of
  545. a very low quality setting, and therefore it takes very little space.
  546. Successive scans improve the quality.  Each scan adds to the data already
  547. provided, so that the total storage requirement is about the same as for a
  548. baseline JPEG image of the same quality as the final scan.  (Basically,
  549. progressive JPEG is just a rearrangement of the same data into a more
  550. complicated order.)
  551.  
  552. The advantage of progressive JPEG is that if an image is being viewed
  553. on-the-fly as it is transmitted, the viewer sees an approximation to the
  554. whole image very quickly, with gradual improvement of quality as one waits
  555. longer; this is much nicer than a slow top-to-bottom display of the image.
  556. The disadvantage is that each scan takes about the same amount of
  557. computation to display as a whole baseline JPEG file would.  So progressive
  558. JPEG only makes sense if one has a decoder that's much faster than the
  559. communication link.
  560.  
  561. Up until recently, there weren't many applications in which progressive JPEG
  562. looked attractive, so hardly any implementations of it are available.  But
  563. with the popularity of WWW browsers running over rather slow modem links,
  564. and with the ever-increasing horsepower of personal computers, progressive
  565. JPEG is starting to look like a win for WWW.  I expect that progressive JPEG
  566. capability will start to appear in WWW browsers during 1995.
  567.  
  568. ------------------------------
  569.  
  570. Subject: [12] Isn't there a lossless JPEG?
  571.  
  572. There's a great deal of confusion on this subject.  The JPEG standard does
  573. include a truly lossless compression algorithm, i.e., one that guarantees
  574. its decompressed output is bit-for-bit identical to the original input.
  575. However, this lossless mode has almost nothing in common with the regular
  576. lossy JPEG algorithm, and it offers much less compression.
  577.  
  578. Lossless JPEG typically compresses full-color data by around 2:1.  Lossless
  579. JPEG works well only on continuous-tone images; it does not provide useful
  580. compression of palette-color images or low-bit-depth images.  (The JBIG
  581. standard is considered superior to lossless JPEG for images of less than
  582. about 6 bits/sample.)
  583.  
  584. At present, very few implementations of lossless JPEG exist.  The PVRG code
  585. mentioned in part 2 handles lossless JPEG.  Another free implementation
  586. is available from ftp.cs.cornell.edu:/pub/multimed/ljpg.tar.Z; this is a
  587. smaller program that handles *only* lossless JPEG.
  588.  
  589. Cranking a regular JPEG implementation up to its maximum quality setting
  590. *does not* get you lossless storage; lossless JPEG is a fundamentally
  591. different method.  Even at the maximum possible quality setting, regular
  592. JPEG cannot be lossless because it is subject to roundoff errors in various
  593. calculations.  The roundoff errors are nearly always too small to be seen,
  594. but they will accumulate if you put the image through multiple cycles of
  595. compression.
  596.  
  597. Many implementations won't even let you get to the maximum possible setting,
  598. because it's such an inefficient way to use regular JPEG.  With the IJG JPEG
  599. software, for example, you have to say not only "-quality 100" but also
  600. "-sample 1x1" to eliminate all deliberate loss of information.  The
  601. resulting files are far larger and of only fractionally better quality than
  602. files generated at more reasonable settings.  And they're still slightly
  603. lossy!  If you really need lossless storage, don't try to approximate it
  604. with regular JPEG.
  605.  
  606. ------------------------------
  607.  
  608. Subject: [13] Why all the argument about file formats?
  609.  
  610. Strictly speaking, JPEG refers only to a family of compression algorithms;
  611. it does *not* refer to a specific image file format.  The JPEG committee was
  612. prevented from defining a file format by turf wars within the international
  613. standards organizations.
  614.  
  615. Since we can't actually exchange images with anyone else unless we agree on
  616. a common file format, this leaves us with a problem.  In the absence of
  617. official standards, a number of JPEG program writers have just gone off to
  618. "do their own thing", and as a result their programs aren't compatible with
  619. anyone else's.
  620.  
  621. The closest thing we have to a standard JPEG format is some work that's been
  622. coordinated by people at C-Cube Microsystems.  They have defined two
  623. JPEG-based file formats:
  624.   * JFIF (JPEG File Interchange Format), a "low-end" format that transports
  625.     pixels and not much else.
  626.   * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is
  627.     a "high-end" format that will let you record just about everything you
  628.     ever wanted to know about an image, and a lot more besides :-).  TIFF
  629.     is far more complex than JFIF, and is generally less transportable,
  630.     because different vendors have often implemented slightly different
  631.     and incompatible subsets of TIFF.  It's not likely that adding JPEG to
  632.     the mix will do anything to improve this situation.
  633. Both of these formats were developed with input from all the major vendors
  634. of JPEG-related products; it's reasonably likely that future commercial
  635. products will adhere to one or both standards.
  636.  
  637. JFIF has emerged as the de-facto standard on Usenet.  JFIF is simpler than
  638. TIFF and is available now; the TIFF 6.0 spec for incorporating JPEG is not
  639. widely implemented, partly because it has some serious design flaws.  It is
  640. likely that the TIFF 6.0 JPEG section will be changed significantly before
  641. widespread adoption occurs.  Even when TIFF/JPEG is well defined, the JFIF
  642. format is likely to be a widely supported "lowest common denominator";
  643. TIFF/JPEG files may never be as transportable as JFIF.
  644.  
  645. A particular case of wide interest is Apple's Macintosh QuickTime software.
  646. QuickTime uses a JFIF-compatible format wrapped inside the Mac-specific PICT
  647. structure.  Conversion between JFIF and PICT/JPEG is pretty straightforward,
  648. and several Mac programs are available to do it (see Mac portion of part 2).
  649. If you have an editor that handles binary files, you can even strip a
  650. PICT/JPEG file down to JFIF by hand; see the next section for details.
  651.  
  652. Another particular case is Handmade Software's DOS programs (GIF2JPG/JPG2GIF
  653. and Image Alchemy).  These programs are capable of reading and writing JFIF
  654. format.  By default, though, they write a proprietary format developed by
  655. HSI.  This format is NOT readable by any non-HSI programs and should not be
  656. used for Usenet postings.  Use the -j switch to get JFIF output.  (This
  657. applies to old versions of these programs; the current releases emit JFIF
  658. format by default.  You still should be careful not to post HSI-format
  659. files, unless you want to get flamed by people on non-PC platforms.)
  660.  
  661. News flash: the ISO JPEG committee seems to have won their turf wars.  They
  662. will define a complete file format spec called "SPIFF" in the next version
  663. of the JPEG standard.  It's pretty late in the game though, so whether this
  664. will have much impact on real-world files remains to be seen.
  665.  
  666. ------------------------------
  667.  
  668. Subject: [14] How do I recognize which file format I have,
  669.           and what do I do about it?
  670.  
  671. If you have an alleged JPEG file that your software won't read, it's likely
  672. to be HSI format or some other proprietary JPEG-based format.  You can tell
  673. what you have by inspecting the first few bytes of the file:
  674.  
  675. 1.  A JFIF-standard file will start with the four bytes (hex) FF D8 FF E0,
  676.     followed by two variable bytes (often hex 00 10), followed by 'JFIF'.
  677.  
  678. 2.  If you see FF D8 at the start, but not the 'JFIF' marker, you may have a
  679.     "raw JPEG" file.  This is probably decodable as-is by JFIF software ---
  680.     it's worth a try, anyway.
  681.  
  682. 3.  HSI files start with 'hsi1'.  You're out of luck unless you have HSI
  683.     software.  Portions of the file may look like plain JPEG data, but they
  684.     usually won't decompress properly with non-HSI programs.
  685.  
  686. 4.  A Macintosh PICT file, if JPEG-compressed, will have several hundred
  687.     bytes of header (often 726 bytes, but not always) followed by JPEG data.
  688.     Look for the 3-byte sequence (hex) FF D8 FF.  The text 'Photo - JPEG'
  689.     will usually appear shortly before this header, and 'AppleMark' or
  690.     'JFIF' will usually appear shortly after it.  Strip off everything
  691.     before the FF D8 FF and you will usually be able to decode the file.
  692.     (This will fail if the PICT image is divided into multiple "bands",
  693.     but that is uncommon.)
  694.  
  695. 5.  If the file came from a Macintosh, it could also be a standard JFIF
  696.     file with a MacBinary header attached.  In this case, the JFIF header
  697.     will appear 128 bytes into the file.  Get rid of the first 128 bytes
  698.     and you're set.
  699.  
  700. 6.  Anything else: it's a proprietary format, or not JPEG at all.  If you
  701.     are lucky, the file may consist of a header and a raw JPEG data stream.
  702.     If you can identify the start of the JPEG data stream (look for FF D8),
  703.     try stripping off everything before that.
  704.  
  705. HSI files used to be rather common in alt.binaries.pictures.* postings,
  706. although thankfully they have gotten less so.  You can spot an HSI posting
  707. by looking at the first few characters of the uuencoded data.  The
  708. characteristic HSI pattern is
  709.     "begin" line
  710.     M:'-I ...
  711. whereas standard JFIF files begin with
  712.     "begin" line
  713.     M_]C_X ...
  714. If you learn to spot the HSI pattern, you can save yourself the trouble
  715. of downloading unusable files.
  716.  
  717. At least one release of Hijaak Pro writes JFIF files that claim to be
  718. revision 2.01.  There is no such spec; the latest JFIF revision is 1.02.
  719. It looks like HiJaak got the high and low bytes backwards.  Unfortunately,
  720. most JFIF readers will give up on encountering these files, because the JFIF
  721. spec defines a major version number change to mean an incompatible format
  722. change.  If there ever *were* a version 2.01, it would be so numbered
  723. because current software could not read it and should not try.  (One wonders
  724. if Hijaak has ever heard of cross-testing with other people's software.)
  725. If you run into one of these misnumbered files, you can fix it with a
  726. binary-file editor, by changing the twelfth byte of the file from 2 to 1.
  727.  
  728. ------------------------------
  729.  
  730. Subject: [15] How does JPEG work?
  731.  
  732. You can find an introduction and references for further reading in the
  733. comp.compression FAQ, which is available from the news.answers archive at
  734. rtfm.mit.edu, in files /pub/usenet/news.answers/compression-faq/part[1-3]
  735. (see also "[20] Where are FAQ lists archived?").
  736.  
  737. The comp.compression FAQ is also a good starting point for information on
  738. other state-of-the-art image compression methods, such as wavelets and
  739. fractals.  A quick comparison: wavelets are likely to be the basis of the
  740. next generation of image-compression standards, but they are perhaps 10
  741. years behind JPEG in the standardization pipeline.  Fractals have been
  742. terribly over-hyped by their chief commercial proponent, and it's difficult
  743. to say what their true capabilities are.
  744.  
  745. ------------------------------
  746.  
  747. Subject: [16] What about arithmetic coding?
  748.  
  749. The JPEG spec defines two different "back end" modules for the final output
  750. of compressed data: either Huffman coding or arithmetic coding is allowed.
  751. The choice has no impact on image quality, but arithmetic coding usually
  752. produces a smaller compressed file.  On typical images, arithmetic coding
  753. produces a file 5 to 10 percent smaller than Huffman coding.  (All the
  754. file-size numbers previously cited are for Huffman coding.)
  755.  
  756. Unfortunately, the particular variant of arithmetic coding specified by the
  757. JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
  758. Thus *you cannot legally use JPEG arithmetic coding* unless you obtain
  759. licenses from these companies.  (Patent law's "experimental use" exception
  760. allows people to test a patented method in the context of scientific
  761. research, but any commercial or routine personal use is infringement.)
  762.  
  763. I recommend that people not use JPEG arithmetic coding; the space savings
  764. isn't great enough to justify the potential legal hassles.  In particular,
  765. arithmetic coding *should not* be used for any images to be exchanged on
  766. Usenet.  Even if you don't care about US patent law, other folks do.
  767.  
  768. ------------------------------
  769.  
  770. Subject: [17] Could an FPU speed up JPEG?  How about a DSP chip?
  771.  
  772. Since JPEG is so compute-intensive, many people suggest that using an
  773. FPU chip (a math coprocessor) should speed it up.  This is not so.
  774. Most production-quality JPEG programs use only integer arithmetic and so
  775. they are unaffected by the presence or absence of floating-point hardware.
  776.  
  777. It is possible to save a few operations by doing the DCT step in floating
  778. point.  On most PC-class machines, FP math is enough slower than integer
  779. math that the overall speed is still much worse with FP.  Some high-priced
  780. workstations and supercomputers have fast enough FP hardware to make an FP
  781. DCT method be a win.
  782.  
  783. DSP (digital signal processing) chips are ideally suited for fast repetitive
  784. integer arithmetic, so programming a DSP to do JPEG can yield significant
  785. speedups.  DSPs are starting to be found as add-ons for PCs and small
  786. workstations, so you can expect to see DSP-based JPEG programs popping up.
  787.  
  788. ------------------------------
  789.  
  790. Subject: [18] Isn't there an M-JPEG standard for motion pictures?
  791.  
  792. As was stated in section 1, JPEG is only for still images.  Nonetheless,
  793. you will frequently see references to "motion JPEG" or "M-JPEG" for video.
  794. *There is no such standard*.  Various vendors have applied JPEG to
  795. individual frames of a video sequence, and have called the result "M-JPEG".
  796. Unfortunately, in the absence of any recognized standard, they've each done
  797. it differently.  The resulting files are usually not compatible across
  798. different vendors.
  799.  
  800. MPEG is the recognized standard for motion picture compression.  It uses
  801. many of the same techniques as JPEG, but adds inter-frame compression to
  802. exploit the similarities that usually exist between successive frames.
  803. Because of this, MPEG typically compresses a video sequence by about a
  804. factor of three more than "M-JPEG" methods can.  The disadvantages of MPEG
  805. are (1) it requires much more computation to generate the compressed
  806. sequence (since detecting visual similarities is hard for a computer), and
  807. (2) it's difficult to edit an MPEG sequence on a frame-by-frame basis
  808. (since each frame is intimately tied to the ones around it).  This latter
  809. problem has made "M-JPEG" methods rather popular for video editing products.
  810.  
  811. It's a shame that there isn't a recognized M-JPEG standard.  But there
  812. isn't, so if you buy a product identified as "M-JPEG", be aware that you
  813. are probably locking yourself into that one vendor.
  814.  
  815. See the MPEG FAQ for more information about MPEG.
  816.  
  817. ------------------------------
  818.  
  819. Subject: [19] What if I need more than 8-bit precision?
  820.  
  821. Baseline JPEG stores images with 8 bits per color sample, in other words
  822. 24 bits per pixel for RGB images, 8 bits/pixel for grayscale, 32 bits/pixel
  823. for CMYK, etc.  There is an extension that stores 12 bits/sample for
  824. applications that need higher accuracy.  Medical images, for example, are
  825. often 12-bit grayscale.  The 12-bit extension is not very widely supported,
  826. however.  One package that does support it is the free IJG source code (see
  827. part 2 of this FAQ).
  828.  
  829. For lossless JPEG, the standard permits any data precision between 2 and 16
  830. bits per sample, but high-precision lossless JPEG is even less widely
  831. supported than high-precision lossy JPEG.  I don't know of any working
  832. noncommercial implementations.  (The Cornell lossless JPEG coder tries to
  833. support it, but reportedly has bugs with data of more than 8 bits.)
  834.  
  835. ------------------------------
  836.  
  837. Subject: [20] Where are FAQ lists archived?
  838.  
  839. Many FAQs are crossposted to news.answers.  Well-run netnews sites will have
  840. the latest versions available in that newsgroup.  However, there are a *lot*
  841. of postings in news.answers, and they can be hard to sort through.
  842.  
  843. The latest versions of news.answers postings are archived at rtfm.mit.edu.
  844. You can retrieve this FAQ by FTP as /pub/usenet/news.answers/jpeg-faq/part1
  845. and /pub/usenet/news.answers/jpeg-faq/part2.  If you have no FTP access,
  846. send e-mail to mail-server@rtfm.mit.edu containing the lines
  847.     send usenet/news.answers/jpeg-faq/part1
  848.     send usenet/news.answers/jpeg-faq/part2
  849. (If you don't get a reply, the server may be misreading your return address;
  850. add a line such as "path myname@mysite" to specify your correct e-mail
  851. address to reply to.)  For more info about the FAQ archive, retrieve the
  852. file rtfm.mit.edu:/pub/usenet/news.answers/news-answers/introduction.
  853.  
  854. The same FAQs are also available in the World Wide Web; see the index at
  855. http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html.  This FAQ
  856. is http://www.cis.ohio-state.edu/hypertext/faq/usenet/jpeg-faq/top.html.
  857. Other WWW FAQ archives include http://www.cs.ruu.nl/cgi-bin/faqwais and
  858. http://www.lib.ox.ac.uk/internet/news/.
  859.  
  860. -- 
  861.             tom lane
  862.             organizer, Independent JPEG Group
  863.             tgl@netcom.com or tgl@sss.pgh.pa.us
  864.  
  865.  
  866. Archive-name: jpeg-faq/part2
  867. Posting-Frequency: every 14 days
  868. Last-modified: 25 June 1995
  869.  
  870. This article answers Frequently Asked Questions about JPEG image compression.
  871. This is part 2, covering system-specific hints and program recommendations
  872. for a variety of computer systems.  Part 1 covers general questions and
  873. answers about JPEG.  As always, suggestions for improvement of this FAQ are
  874. welcome.
  875.  
  876. New since version of 28 May 1995:
  877.   * New versions of ImageMagick (3.6.3), zgv (2.6).
  878.  
  879.  
  880. This article includes the following sections:
  881.  
  882. General info:
  883.  
  884. [1] What is covered in this FAQ?
  885. [2] How do I retrieve these programs?
  886.  
  887. Programs and hints for specific systems:
  888.  
  889. [3] X Windows
  890. [4] Unix (without X)
  891. [5] MS-DOS
  892. [6] Microsoft Windows
  893. [7] OS/2
  894. [8] Macintosh
  895. [9] Amiga
  896. [10] Atari ST
  897. [11] Acorn Archimedes
  898. [12] NeXT
  899. [13] Other systems
  900.  
  901. Source code for JPEG:
  902.  
  903. [14] Freely available source code for JPEG
  904.  
  905. Miscellaneous:
  906.  
  907. [15] Where are FAQ lists archived?
  908.  
  909.  
  910. This article and its companion are posted every 2 weeks.  If you can't find
  911. part 1, you can get it from the news.answers archive at rtfm.mit.edu
  912. (see "[15] Where are FAQ lists archived?"). This article changes frequently;
  913. get a new copy if the one you are reading is more than a couple months old.
  914.  
  915. ------------------------------
  916.  
  917. Subject: [1] What is covered in this FAQ?
  918.  
  919. This list describes programs that are of particular interest to JPEG users.
  920. For the most part, I concentrate on viewers, since a viewer program is the
  921. first thing you'll need.  Some general image-editing programs are listed
  922. too, especially if they are useful as plain viewers (meaning that they can
  923. load and display an image as quickly and easily as a dedicated viewer).
  924. Programs that convert JPEG to and from other image file formats are also
  925. covered.
  926.  
  927. I list only freeware and shareware programs that are available on the
  928. Internet by FTP.  Commercial products are intentionally excluded, to keep
  929. the list to a reasonable size and to avoid any appearance of advertising.
  930. Also, I try to list only programs that are popular among Usenet users, as
  931. indicated by comments and recommendations in news articles.  I have no
  932. access to many of the types of systems covered here, so I have to rely on
  933. what other people say about a program to decide whether to list it.  If you
  934. have an opinion pro or con on any program, I'd appreciate hearing it.
  935.  
  936. This FAQ also includes a few hints that are specific to a machine or
  937. program, and thus don't belong in the general discussion of part 1.
  938.  
  939. ------------------------------
  940.  
  941. Subject: [2] How do I retrieve these programs?
  942.  
  943. All the files mentioned in this FAQ are available by standard Internet FTP.
  944. If you don't know how to use FTP, please read the article "Anonymous FTP
  945. FAQ List", which you can get by sending e-mail to mail-server@rtfm.mit.edu
  946. with the single line "send usenet/news.answers/ftp-list/faq" in the body.
  947. (See also "[15] Where are FAQ lists archived?")  This section gives some
  948. quick reminders which are not meant as a substitute for reading the FTP FAQ.
  949.  
  950. If you do not have direct access to FTP, you can use an "ftpmail" server to
  951. obtain files by e-mail.  See the FTP FAQ for details.
  952.  
  953. If you use a WWW browser such as Mosaic or Lynx, it will do FTP for you.
  954. To retrieve a file described here as "site.name:/path/to/file", tell the
  955. browser to open the URL "ftp://site.name/path/to/file".  (If you are reading
  956. this FAQ in the WWW FAQ archive, the file names should appear as links that
  957. you can just click on.)  Don't forget to set save-to-disk mode first.
  958.  
  959. Many of the pointers given here refer to popular central archive sites,
  960. such as oak.oakland.edu for DOS software or sumex-aim.stanford.edu for Mac.
  961. These sites are often overloaded, and are likely to refuse your connection
  962. request when they are busy.  You can try again at a less popular time of
  963. day, or you can look for a "mirror site".  Most central archive sites have
  964. groups of mirror sites that keep copies of their files.  Find out the name
  965. of the mirror site closest to you, and visit that site instead; it's good
  966. net citizenship and you'll get faster response.  Check the FAQs for the
  967. newsgroups specific to your system type to find lists of mirror sites.
  968. (The archive site may list some mirror sites in its connection-refused error
  969. message.  Unfortunately, some FTP programs won't show you the whole message.
  970. WWW browsers are often bad about this.)
  971.  
  972. If you are able to reach the archive site, but the file you want doesn't
  973. exist, most likely it's been replaced by a newer version.  Get a directory
  974. listing of the directory that's supposed to contain the file, and look for
  975. a file with a similar name but a higher version number.  (If you find an
  976. out-of-date reference in a *current* version of the JPEG FAQ, I'd
  977. appreciate hearing about it by e-mail.)
  978.  
  979. Practically all of the files listed here are compressed archive files.
  980. This means you need to retrieve them in binary mode.  (WWW browsers do this
  981. automatically, but many older FTP programs must be told to use binary mode.)
  982. Once you've got the archive file, you'll need a decompressor/dearchiver
  983. to extract the program and documentation files inside it.  Check the FAQs
  984. for your system type to find out where to get dearchiver programs.
  985.  
  986. ------------------------------
  987.  
  988. Subject: [3] X Windows
  989.  
  990. XV is an excellent viewer for JPEG, GIF, and many other image formats.
  991. It can also do format conversion and some simple image manipulations.
  992. Get it from ftp.cis.upenn.edu:/pub/xv/xv-3.10.tar.gz.  Shareware, $25.
  993. Version 3.10 has some nifty new features, and it loads JPEGs noticeably
  994. faster than any prior version.  If you're still using version 2.anything,
  995. it's definitely time to upgrade.  HINT: if you have an 8-bit display then
  996. you need to "lock 8-bit mode" to get decent display of JPEG images.  (But
  997. do NOT do this if you intend to resave the image, because it'll be written
  998. from the 8-bit version, thus costing you image quality.)  You can set this
  999. mode to be default by adding "xv.force8: true" to your .Xdefaults file.
  1000.  
  1001. Another excellent choice is John Cristy's free ImageMagick package,
  1002. ftp.x.org:/contrib/applications/ImageMagick/ImageMagick-3.6.3.tar.gz.  This
  1003. package handles many image processing and conversion tasks.  The ImageMagick
  1004. viewer handles 24-bit displays correctly; for colormapped displays, it does
  1005. better (though slower) color quantization than XV or the basic IJG JPEG
  1006. software.
  1007.  
  1008. Both of the above are large, complex packages.  If you just want a simple
  1009. image viewer, try xloadimage or xli.  xloadimage views and converts many
  1010. image file types including JPEG.  Version 4.1 has better JPEG support than
  1011. prior versions and is easier to install.  xloadimage is free and available
  1012. from ftp.x.org:/R5contrib/xloadimage.4.1.tar.gz.  xli is a variant version
  1013. of xloadimage; xli is slightly better as an interactive viewer, but it can't
  1014. be used as a converter, and it supports fewer file formats.  xli is also
  1015. free and available from ftp.x.org:/contrib/applications/xli.1.16.tar.gz.
  1016.  
  1017. ------------------------------
  1018.  
  1019. Subject: [4] Unix (without X)
  1020.  
  1021. If you want a command-line JPEG conversion program, see the IJG source code
  1022. described in section 14.  (This code is included as a subdirectory in most
  1023. of the X programs described above, although they may not have the latest
  1024. version.)
  1025.  
  1026. Non-X viewers are hard to come by, since they are very hardware dependent.
  1027. Linux users with VGA/SVGA displays may like zgv.  Version 2.6 is available
  1028. from sunsite.unc.edu:/pub/Linux/apps/graphics/viewers/zgv2.6-bin.tar.gz.
  1029. (Several other alternatives are available in the same directory.)
  1030. If you use a less popular platform, you're probably out of luck.
  1031.  
  1032. ------------------------------
  1033.  
  1034. Subject: [5] MS-DOS
  1035.  
  1036. This covers plain DOS; for Windows or OS/2 programs, see the next sections.
  1037.  
  1038. NOTE ABOUT SIMTEL FILES: The largest Internet collection of PC-related
  1039. programs is the Simtel archives (named for the original archive site, now
  1040. defunct).  The principal archive site for these files is oak.oakland.edu,
  1041. which keeps Simtel files under /SimTel; so files in the msdos/graphics
  1042. section of the archives are at oak.oakland.edu:/SimTel/msdos/graphics/.
  1043. There are many mirror sites which keep copies of the Simtel files; for
  1044. quickest response you should use the mirror site closest to you.  Consult
  1045. the periodic postings in comp.archives.msdos.announce to find your nearest
  1046. mirror site.  If you have no FTP capability, the same postings will tell you
  1047. how to retrieve Simtel files by e-mail.
  1048.  
  1049. QPV (formerly called QPEG) is the fastest noncommercial JPEG viewer I know
  1050. of.  In exchange for speed, QPV gives up some image quality, particularly on
  1051. 256-or-less-color displays.  Its best feature is a really-fast small preview
  1052. window, which is great for searching through lots of image files. Also views
  1053. GIF,TGA,BMP,PNG.  Requires 386-or-better CPU and VGA-or-better display card.
  1054. Current version is 1.6c, available from
  1055. ftp.tu-clausthal.de:/pub/msdos/graphics/qpv16c.zip.  In the USA, a closer
  1056. site is ftp.best.com:/pub/bryanw/qpv/.  Shareware, $20.
  1057.  
  1058. DVPEG is a free viewer for JPEG, GIF, Targa, and PPM files.  Current version
  1059. is 3.0l, available from sunee.uwaterloo.ca:/pub/jpeg/viewers/dvpeg30l.zip.
  1060. (That's lower case l, not digit 1.)  This is a good basic viewer that works
  1061. on either 286 or 386/486 machines.  The user interface is clunky but
  1062. functional.  DVPEG is substantially faster than it used to be; on hi-color
  1063. displays it is nearly as fast as QPV.  On 8-bit displays, its two-pass
  1064. quantization mode is slow but gives much better image quality than QPV can
  1065. provide.
  1066.  
  1067. Lesser-used DOS viewers include:
  1068. * DISPLAY, alias DISP.  The Swiss army knife of DOS viewers.  Does almost
  1069.   everything, but a bit intimidating for newcomers.  User interface is much
  1070.   improved over early versions, but still awkward in places.  Requires 386
  1071.   or better.  Freeware.  Current version is 1.87, available from
  1072.   nctuccca.edu.tw:/PC/graphics/disp/disp187a.zip and disp187b.zip.
  1073. * GDS.  A well-done viewer and image converter for many image formats.
  1074.   Installation is simple, and the on-line documentation is very good.
  1075.   JPEG loading is a bit slower than the above viewers, though.  Shareware,
  1076.   $40.  Current version is 3.1f.  A slightly restricted demo version is
  1077.   available from ftp.netcom.com:/pub/ph/photodex/gds31f.zip.
  1078. * NVIEW.  Views JPEG and half a dozen other image formats.  Easy to use,
  1079.   very easy to install.  Only moderately fast, but it has lots of options.
  1080.   Supports hi-color and true-color modes on some cards, but not mine :-(.
  1081.   Requires 386 or better.  Current version is 1.50, available from Simtel
  1082.   sites, file msdos/graphics/nview150.zip.  Shareware, $29.
  1083. * CSHOW or CompuShow (recently renamed 2SHOW).  This is a widely used viewer
  1084.   for GIF and other formats.  Versions prior to CSHOW 9.00 or 2SHOW 2.00 had
  1085.   absolutely abysmal JPEG support; if you have one of those, toss it and get
  1086.   a newer version.  The current release is still the slowest DOS JPEG viewer
  1087.   listed here, but it's faster than it used to be, and image quality and
  1088.   robustness have improved substantially.  The main reason to use CSHOW
  1089.   as a JPEG viewer is that it supports a wide range of pre-VGA display
  1090.   hardware; most of the above viewers require VGA or better.  Also, CSHOW
  1091.   doesn't require a 386.  Current version is 2.03, available from Simtel
  1092.   sites, file msdos/gif/2show203.zip.  Shareware, $39.
  1093.  
  1094. Due to the remarkable variety of PC graphics hardware, any one of these
  1095. viewers might not work on your particular machine.  If you can't get *any*
  1096. of them to work, you'll need to use one of the following conversion programs
  1097. to convert JPEG to GIF, then view with your favorite GIF viewer.  (If you
  1098. have hi-color hardware, don't use GIF as the intermediate format; try to
  1099. find a hi-color BMP- or TARGA-capable viewer instead.)
  1100.  
  1101. The free IJG JPEG converters are available from Simtel sites, file
  1102. msdos/graphics/jpg5a.zip (or jpg5a386.zip if you have a 386 or better CPU
  1103. and extended memory).  These programs will convert JPEG to and from GIF,
  1104. BMP, Targa, and PPM formats; they are DOS compilations of the free source
  1105. code described in section 14.
  1106.  
  1107. Handmade Software offers free JPEG<=>GIF conversion tools, GIF2JPG/JPG2GIF.
  1108. These are quite slow and are limited to conversion to and from GIF format;
  1109. thus they can't produce 24-bit color output from a JPEG.  The sole advantage
  1110. of these tools is that they will read and write HSI's proprietary JPEG
  1111. format as well as the Usenet-standard JFIF format.  Since HSI-format files
  1112. are rather widespread on BBSes, this is a useful capability.  Version 2.0
  1113. of these tools is free (prior versions were shareware).  Get it from Simtel
  1114. sites, file msdos/graphics/gif2jpg2.zip.
  1115. NOTE: do not use HSI format for files to be posted on Usenet, since it is
  1116. not readable by any non-HSI software.
  1117.  
  1118. Handmade Software also has a shareware image conversion and manipulation
  1119. package, Image Alchemy.  This will translate JPEG files (both JFIF and HSI
  1120. formats) to and from many other image formats.  It can also display images.
  1121. A demo version of Image Alchemy version 1.77 is available from Simtel sites,
  1122. file msdos/graphics/alch177.zip.
  1123.  
  1124. JPGINDEX is a useful tool for making indexes of JPEG image collections.
  1125. Available from Simtel sites, file msdos/graphics/jpgidx13.zip.
  1126.  
  1127. ------------------------------
  1128.  
  1129. Subject: [6] Microsoft Windows
  1130.  
  1131. ACDSee is a very fast, easy to use JPEG/GIF/BMP/TGA viewer.  Good viewing
  1132. and browsing capabilities, but no image editing or conversion.  Current
  1133. version is 1.24, available from
  1134. ftp.cica.indiana.edu:/pub/pc/win3/desktop/acdc124.zip.  Shareware, $15.
  1135.  
  1136. LView Pro is a viewer/editor/converter for JPEG, GIF, BMP, and other
  1137. formats.  Version 1.B is available from Simtel sites (see NOTE in previous
  1138. section), file win3/graphics/lviewp1b.zip.  Requires 386 or better CPU.
  1139. LView Pro offers a wide array of image editing functions and can load JPEGs
  1140. in either fast/low-quality or slow/high-quality modes.  Shareware payment
  1141. ($30) is required only for business usage or to obtain versions optimized
  1142. for Win32s/NT, 486 or Pentium CPUs.
  1143.  
  1144. WinECJ is a fast, no-frills viewer with image quality noticeably worse than
  1145. most other JPEG viewers.  (You can purchase a version with better image
  1146. quality for AUD$30.)  Version 1.2 is free and available from Simtel sites,
  1147. file win3/graphics/winecj12.zip.  Requires Windows 3.1 and
  1148. 256-or-more-colors mode.
  1149.  
  1150. WinJPEG (shareware, $25) displays JPEG,GIF,Targa,TIFF,PCX, and BMP files;
  1151. it can write all of these formats too, so it can be used as a converter.
  1152. It has some other nifty features including screen capture, color-balance
  1153. adjustment, and slideshow.  The current version is 2.65, available from
  1154. Simtel sites, file win3/graphics/winjp265.zip.  (This is a 286-compatible
  1155. version; if you register, you'll get the 386-and-up version, which is
  1156. roughly twice as fast.)
  1157.  
  1158. Some people prefer Paint Shop Pro.  It's not very impressive as just a JPEG
  1159. viewer (especially since image quality is not very good on 8-bit displays),
  1160. but it has lots of image manipulation features.  Current version is 2.00,
  1161. available from ftp.cica.indiana.edu:/pub/pc/win3/desktop/pspro200.zip.
  1162. Shareware, $69.
  1163.  
  1164. QPV and DVPEG (see section 5) work under Windows, but only in full-screen
  1165. mode, not in a window.  Also note that you can run the DOS conversion
  1166. programs described earlier inside a Windows DOS window.
  1167.  
  1168. Native Windows NT viewers are starting to appear.  A couple of popular
  1169. ones are:
  1170. * NTj.  Reads JPEG, GIF, and BMP.  Available from
  1171.   ftp.digital.com:/pub/DEC/NTj/NTj-x86.exe (or NTj.exe for the DEC Alpha
  1172.   version).  Freeware.
  1173. * PolyView.  Reads JPEG, GIF, BMP, Photo-CD.  Current version is 1.70,
  1174.   available from ftp.cica.indiana.edu:/pub/pc/win3/nt/polyv170.zip.
  1175.   Shareware, $20.
  1176.  
  1177. ------------------------------
  1178.  
  1179. Subject: [7] OS/2
  1180.  
  1181. The most widely used OS/2 JPEG viewers are:
  1182.  
  1183. JoeView 1.22b: free JPEG/GIF/BMP/PCX/TIFF viewer.  Available from
  1184. hobbes.nmsu.edu:/os2/graphics/jovw122b.zip.
  1185.  
  1186. PMJPEG 1.63: OS/2 2.x port of WinJPEG, a popular viewer/converter for
  1187. Windows (see description in previous section).  Shareware, $20.  Available
  1188. from hobbes.nmsu.edu:/os2/graphics/pmjpg163.zip.
  1189.  
  1190. PMView 0.90: JPEG/GIF/BMP/Targa/etc viewer.  GIF viewing very fast, JPEG
  1191. viewing roughly the same speed as the above two programs.  Has image
  1192. manipulation & slideshow functions.  Shareware, $35.  Available from
  1193. hobbes.nmsu.edu:/os2/graphics/pmview90.zip.
  1194.  
  1195. All of these viewers require Palette Manager for best display quality.
  1196. Opinion seems to be about equally split as to which is the best, so try
  1197. them all to see which one you like.
  1198.  
  1199. Possibilities for file format conversion include:
  1200.  
  1201. Image Archiver 1.03: image conversion/viewing with PM graphical interface.
  1202. Strong on conversion functions, viewing is a bit weaker.  Shareware, $15.
  1203. hobbes.nmsu.edu:/os2/graphics/imgarc13.zip.
  1204.  
  1205. hobbes.nmsu.edu:/os2/graphics/jpegv4.zip is a 32-bit version of the free IJG
  1206. conversion programs, version 4.  (Version 5 is stuck in the archive admin's
  1207. input queue :-(.)
  1208.  
  1209. hobbes.nmsu.edu:/os2/graphics/jpeg4_16.zip is a 16-bit version of
  1210. same, suitable for OS/2 1.x.
  1211.  
  1212. Note: the hobbes OS/2 collection is mirrored at ftp-os2.cdrom.com.
  1213.  
  1214. ------------------------------
  1215.  
  1216. Subject: [8] Macintosh
  1217.  
  1218. Most Mac JPEG programs rely on Apple's JPEG implementation, which is part of
  1219. the QuickTime system extension; so you need to have QuickTime installed.
  1220. To use QuickTime, you need a 68020 or better CPU and you need to be running
  1221. System 6.0.7 or later.  (If you're running System 6, you must also install
  1222. the 32-bit QuickDraw extension; in System 7, that is built in.)  The latest
  1223. freely available version of QuickTime is 1.6.1, available from
  1224. ftp.apple.com:/dts/mac/sys.soft/quicktime/quicktime-1-6-1.hqx.
  1225.  
  1226. Mac users should keep in mind that QuickTime's JPEG format, PICT/JPEG, is
  1227. not the same as the Usenet-standard JFIF JPEG format.  (See part 1 for
  1228. details.)  If you post images on Usenet, make sure they are in JFIF format.
  1229. Most of the programs mentioned here can handle either format.
  1230.  
  1231. The two major Internet sites for Mac software are sumex-aim.stanford.edu and
  1232. mac.archive.umich.edu.  Unfortunately they are both very busy, so you may
  1233. have better luck getting files from a mirror site.  (In fact, these days
  1234. you *must* use a mirror site for sumex-aim; the primary archive only allows
  1235. mirror sites to log in!)  See "Introductory Macintosh Frequently Asked
  1236. Questions" in the comp.sys.mac.* newsgroups for the current locations of
  1237. mirrors.
  1238.  
  1239. JPEGView is an excellent free program for viewing JFIF,PICT/JPEG,GIF,TIFF,
  1240. and other image files.  It can convert between the two JPEG formats and can
  1241. create preview images for files.  The current version is 3.3.1, available
  1242. from sumex-aim.stanford.edu:/info-mac/grf/util/jpeg-view-331.hqx.  Requires
  1243. System 7; QuickTime is optional.  JPEGView usually produces the best color
  1244. image quality of all the currently available Mac JPEG viewers, and it needs
  1245. much less memory to view large images than most other Mac viewers.  Given
  1246. a large image, JPEGView automatically scales it down to fit on the screen,
  1247. rather than presenting scroll bars like most other viewers.  (You can zoom
  1248. in on any desired portion, though.)  Some people like this behavior, some
  1249. don't.  Overall, JPEGView's user interface is very well thought out.
  1250.  
  1251. GIFConverter, a shareware ($40) image viewer/editor/converter, supports
  1252. JFIF,PICT/JPEG,GIF, and many other image formats.  Current version is 2.3.7,
  1253. mac.archive.umich.edu:/mac/graphics/graphicsutil/gifconverter2.37.cpt.hqx.
  1254. Requires System 6.0.5 or later.  GIFConverter is not better than JPEGView as
  1255. a plain JPEG/GIF viewer, but it has much more extensive image manipulation
  1256. and format conversion capabilities.  Also, GIFConverter can load and save
  1257. JFIF images *without* QuickTime, so it is your best bet if your machine is
  1258. too old to run QuickTime.  (But it's faster with QuickTime.)  Hint: if
  1259. GIFConverter runs out of memory while loading a large JPEG, try converting
  1260. the file to GIF with JPEG Convert, then viewing the GIF version.
  1261.  
  1262. A competitor to GIFConverter is GraphicConverter, also shareware ($35).
  1263. Current version is 2.1.2, available at
  1264. sumex-aim.stanford.edu:/info-mac/grf/util/graphic-converter-212.hqx.
  1265. Requires System 7 and QuickTime to handle JPEG.  GraphicConverter has even
  1266. more functionality than GIFConverter, but is correspondingly larger.  Worth
  1267. checking out if you want to manipulate images, not just look at them.
  1268.  
  1269. JPEG Convert, a Mac version of the free IJG JPEG conversion utilities, is
  1270. available at sumex-aim.stanford.edu:/info-mac/app/jpeg-convert-10.hqx.
  1271. This will run on any Mac, but it only does file conversion, not viewing.
  1272. You can use it in conjunction with any GIF viewer.
  1273.  
  1274. Storm Technology's Picture Decompress is a free JPEG viewer/converter.
  1275. This rather old program is inferior to the above programs in many ways, but
  1276. it will run without System 7 or QuickTime, so you may be forced to use it on
  1277. older systems.  (It needs 32-bit QuickDraw, so really old machines can't use
  1278. it.)  File sumex-aim.stanford.edu:/info-mac/app/picture-decompress-201.hqx.
  1279.  
  1280. If your Mac is too old to run 32-bit QuickDraw (a Mac Plus for instance),
  1281. GIFConverter is your only choice for single-program JPEG viewing.  If you
  1282. don't want to pay for GIFConverter, use JPEG Convert and a free GIF viewer.
  1283.  
  1284. More and more commercial Mac applications are supporting JPEG, although not
  1285. all can deal with the Usenet-standard JFIF format.  Adobe Photoshop, version
  1286. 2.0.1 or later, can read and write JFIF-format JPEG files.  (In 2.0.1, use
  1287. the JPEG plug-in on the Acquire menu; 2.5 and later handle JPEG the same as
  1288. other file types.)  You must set the file type code of a downloaded JPEG
  1289. file to 'JPEG' to allow Photoshop to recognize it.
  1290.  
  1291. HINT: if you use Fetch to retrieve files by FTP, add ".jpg" to its list of
  1292. binary file types under Customize/Suffix Mapping.  Otherwise Fetch's
  1293. "automatic" retrieval mode will retrieve JPEGs in text mode, thus corrupting
  1294. the data.
  1295.  
  1296. ------------------------------
  1297.  
  1298. Subject: [9] Amiga
  1299.  
  1300. Most programs listed in this section are available from "AmiNet" archive
  1301. sites.  The master AmiNet site is wuarchive.wustl.edu, but there are many
  1302. mirror sites and you should try to use the closest one.
  1303.  
  1304. Osma Ahvenlampi posted a good review of Amiga picture viewers in
  1305. comp.sys.amiga.reviews in March 1994.  You can retrieve it from
  1306. math.uh.edu:/pub/Amiga/comp.sys.amiga.reviews/software/graphics/PictureViewerSurvey_2.
  1307. Opinions here are mostly stolen from his article.
  1308.  
  1309. FastView is a fast, high-quality JPEG/GIF/ILBM viewer.  It's new but has
  1310. achieved a good reputation in a short time.  Works well on both ECS and AGA
  1311. displays.  Shareware, $15; requires OS 2.0.  Version 1.41 is available from
  1312. Aminet sites, file /pub/aminet/gfx/show/FView141.lha.
  1313.  
  1314. FastJPEG is a free JPEG viewer; it's fast and has good image quality, but it
  1315. doesn't view any formats except JPEG.  Somewhat faster than FastView on ECS
  1316. machines, slower on AGA.  Version 1.10 is available from Aminet sites, file
  1317. /pub/aminet/gfx/show/FastJPEG_1.10.lha.
  1318.  
  1319. PPShow is a good free JPEG/GIF/ILBM/ANIM/Datatype viewer.  Version 4.0 is
  1320. available from Aminet sites, file /pub/aminet/gfx/show/PPShow40.lha.  For
  1321. viewing JPEGs it is a little slower than FastJPEG, and image quality is not
  1322. as good (particularly on ECS machines); but if you want to use just one
  1323. viewer, PPShow is the one.
  1324.  
  1325. HamLab Plus is an excellent JPEG viewer/converter, as well as being a
  1326. general image manipulation tool.  It's cheap (shareware, $20) and can read
  1327. several formats besides JPEG.  The current version is 2.0.8.  A demo version
  1328. is available from AmiNet sites, file /pub/aminet/gfx/edit/hamlab208d.lha.
  1329. The demo version will crop images larger than 512x512, but it is otherwise
  1330. fully functional.
  1331.  
  1332. Rend24 (shareware, $30) is an image renderer that can display JPEG, ILBM,
  1333. and GIF images.  The program can be used to create animations, even
  1334. capturing frames on-the-fly from rendering packages like Lightwave.
  1335. The current version is 1.05, available from AmiNet sites, file
  1336. /pub/aminet/gfx/aga/rend105.lha.
  1337.  
  1338. Viewtek is a free JPEG/ILBM/GIF/ANIM viewer.  The current version is 2.1,
  1339. available from AmiNet sites, file /pub/aminet/gfx/show/ViewTEK21.lha.
  1340. Viewtek used to be the best free JPEG viewer for Amiga, but it now faces
  1341. stiff competition from FastJPEG and PPShow.  The choice depends on your
  1342. display hardware and personal preferences.  Viewtek has poor display quality
  1343. on OCS/ECS (HAM6) screens; but it looks very good on AGA (HAM8).
  1344.  
  1345. There is finally a good JPEG datatype for use with datatype-based viewers
  1346. (such as Multiview or ShowDT).  Available from AmiNet sites, file
  1347. /pub/aminet/util/dtype/jfif_dtc.lha.  (The version dated 12/12/94
  1348. has a bug; you should also get /pub/aminet/util/dtype/jfif_FIX.lha.)
  1349.  
  1350. The free IJG JPEG software is available compiled for Amigas from AmiNet
  1351. sites, file /pub/aminet/gfx/conv/jpegV5Bbin.lha.  These programs convert
  1352. JPEG to/from PPM, GIF, BMP, Targa formats.
  1353.  
  1354. If you have a DCTV box or a compatible display, try JPEGonDCTV.  Available
  1355. from AmiNet sites, file /pub/aminet/gfx/show/JPEGonDCTV100.lha.  Viewtek is
  1356. also reported to work well with DCTV.
  1357.  
  1358. ------------------------------
  1359.  
  1360. Subject: [10] Atari ST
  1361.  
  1362. GEM-View (shareware, $26) displays JPEG, GIF, and other image formats.
  1363. FTP from atari.archive.umich.edu:/atari/Graphics/Gemview/gview248.lzh.
  1364. This is a well regarded viewer.  The English documentation tends to be a
  1365. few versions behind, though.
  1366.  
  1367. For monochrome ST monitors, try MGIF, which manages to achieve four-level
  1368. gray-scale effect by flickering.  Version 4.2 loads JPEG files much faster
  1369. than 4.1 did.  FTP from atari.archive.umich.edu:/atari/Graphics/mgif42b.zoo.
  1370.  
  1371. The free IJG JPEG software is available compiled for Atari ST/TT/etc
  1372. from micros.hensa.ac.uk:/micros/atari/tos/p/p108/jpeg5abn.zoo.
  1373. These programs convert JPEG to/from PPM, GIF, BMP, Targa formats.
  1374.  
  1375. ------------------------------
  1376.  
  1377. Subject: [11] Acorn Archimedes
  1378.  
  1379. The Acorn archive at micros.hensa.ac.uk contains several JPEG-capable
  1380. programs.  Read the file micros.hensa.ac.uk:/micros/arch/riscos/index
  1381. for retrieval instructions.  Recommended archive entries include:
  1382.  
  1383. a022 Translator 7.18: image file format converter (shareware)
  1384. b008 FYEO 2.01: For Your Eyes Only, fast JPEG/GIF image viewer (shareware)
  1385. a110 JPEG 5.00: IJG v5 software (JPEG<=>PPM,GIF,Targa) w/ desktop front end
  1386.  
  1387. !ChangeFSI, supplied with RISC OS 3 version 3.10, can convert from and view
  1388. JPEG JFIF format.  Provision is also made to convert images to JPEG,
  1389. although this must be done from the CLI rather than by double-clicking.
  1390.  
  1391. ------------------------------
  1392.  
  1393. Subject: [12] NeXT
  1394.  
  1395. OmniImageFilter is a filter package that converts NeXTStep TIFF to and from
  1396. about 30 image formats.  It reads JPEG but does not write it.  It works with
  1397. most NeXTStep programs that handle drag-and-drop.  OmniImage is a simple
  1398. image viewer that uses the filter package.  Both are free.  Available from
  1399. ftp.omnigroup.com:/pub/software/OmniImageFilter-3.0.pkg.tar and
  1400. ftp.omnigroup.com:/pub/software/OmniImage-3.0.1.pkg.tar.
  1401.  
  1402. ImageViewer is a PD utility that displays images and can do some format
  1403. conversions.  The current version reads JPEG but does not write it.
  1404. ImageViewer is available from the NeXT archives at sonata.cc.purdue.edu and
  1405. cs.orst.edu:/pub/next/3.0/bin/ImageViewer0.9i.tar.Z.  Note that there
  1406. is an older version floating around that does not support JPEG.
  1407.  
  1408. NeXTStep includes built-in support for TIFF/JPEG, but not for the
  1409. Usenet-standard JFIF format.  Be warned that the TIFF/JPEG standard is
  1410. about to change away from the flavor currently produced by NeXTStep,
  1411. so compatibility with other platforms is doubtful.
  1412.  
  1413. ------------------------------
  1414.  
  1415. Subject: [13] Other systems
  1416.  
  1417. If you don't see what you want for your machine, check out the free IJG
  1418. source code described in the next section.  Assuming you have a C compiler
  1419. and at least a little knowledge of compiling C programs, you should be able
  1420. to prepare JPEG conversion programs from the source code.  You'll also need
  1421. a viewer program.  If your display is 8 bits or less, any GIF viewer will do
  1422. fine; if you have a display with more color capability, try to find a viewer
  1423. that can read Targa, BMP, or PPM 24-bit image files.
  1424.  
  1425. ------------------------------
  1426.  
  1427. Subject: [14] Freely available source code for JPEG
  1428.  
  1429. Free, portable C code for JPEG compression is available from the Independent
  1430. JPEG Group.  Source code, documentation, and test files are included.
  1431. Version 5b is available from ftp.uu.net:/graphics/jpeg/jpegsrc.v5b.tar.gz.
  1432. If you are on a PC you may prefer ZIP archive format, which you can find at
  1433. oak.oakland.edu:/SimTel/msdos/graphics/jpgsrc5a.zip (or at any Simtel mirror
  1434. site).  On CompuServe, see the GRAPHSUPPORT forum (GO GRAPHSUP), library 12,
  1435. file jpgs5a.zip.
  1436.  
  1437. The IJG code includes a reusable JPEG compression/decompression library,
  1438. plus sample applications "cjpeg" and "djpeg", which perform conversion
  1439. between JPEG JFIF format and image files in PPM/PGM (PBMPLUS), GIF, BMP,
  1440. Utah RLE, and Targa formats.  Two small applications "wrjpgcom" and
  1441. "rdjpgcom" insert and extract textual comments in JFIF files.
  1442. The package is highly portable; it has been used successfully on many
  1443. machines ranging from Apple IIs to Crays.
  1444.  
  1445. The IJG code is free for both noncommercial and commercial use; only an
  1446. acknowledgement in your documentation is required to use it in a product.
  1447. (See the README file in the distribution for details.)
  1448.  
  1449.  
  1450. A different free JPEG implementation, written by the PVRG group at Stanford,
  1451. is available from havefun.stanford.edu:/pub/jpeg/JPEGv1.2.tar.Z.  The PVRG
  1452. code is designed for research and experimentation rather than production
  1453. use; it is slower, harder to use, and less portable than the IJG code, but
  1454. the PVRG code is easier to understand.  Also, the PVRG code supports
  1455. lossless JPEG, while the IJG code does not.
  1456.  
  1457. ------------------------------
  1458.  
  1459. Subject: [15] Where are FAQ lists archived?
  1460.  
  1461. Many FAQs are crossposted to news.answers.  Well-run netnews sites will have
  1462. the latest versions available in that newsgroup.  However, there are a *lot*
  1463. of postings in news.answers, and they can be hard to sort through.
  1464.  
  1465. The latest versions of news.answers postings are archived at rtfm.mit.edu.
  1466. You can retrieve this FAQ by FTP as /pub/usenet/news.answers/jpeg-faq/part1
  1467. and /pub/usenet/news.answers/jpeg-faq/part2.  If you have no FTP access,
  1468. send e-mail to mail-server@rtfm.mit.edu containing the lines
  1469.     send usenet/news.answers/jpeg-faq/part1
  1470.     send usenet/news.answers/jpeg-faq/part2
  1471. (If you don't get a reply, the server may be misreading your return address;
  1472. add a line such as "path myname@mysite" to specify your correct e-mail
  1473. address to reply to.)  For more info about the FAQ archive, retrieve the
  1474. file rtfm.mit.edu:/pub/usenet/news.answers/news-answers/introduction.
  1475.  
  1476. The same FAQs are also available in the World Wide Web; see the index at
  1477. http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html.  This FAQ
  1478. is http://www.cis.ohio-state.edu/hypertext/faq/usenet/jpeg-faq/top.html.
  1479. Other WWW FAQ archives include http://www.cs.ruu.nl/cgi-bin/faqwais and
  1480. http://www.lib.ox.ac.uk/internet/news/.
  1481.  
  1482. -- 
  1483.             tom lane
  1484.             organizer, Independent JPEG Group
  1485.             tgl@netcom.com or tgl@sss.pgh.pa.us
  1486.  
  1487.  
  1488.